Information is sent over conventional optical networks as a series of digital bytes. There are no analog values on the optical line to mark start or end of a frame. With a pure stream of bytes, it is not possible to tell where a particular frame starts and ends. Frame delineation is a method to mark the boundaries of a frame with special patterns or parameters so that a receiving device can separate frames within an incoming byte stream.
Conventional slow-speed wide area network (WAN) links and optical networks with Packet-over-SONET (POS) transports use a technique called High-Level Data Link Control (HDLC) to delineate frames. The HDLC method uses a unique byte value of 0x7E (hexadecimal) as a frame delimiter to mark the beginning and the end of each frame. Special coding is used inside each frame to make sure that any data pattern that matches the frame delimiter is converted to special codes to avoid false start/end indications.
Referring to FIG. 1, a drawing of a conventional HDLC encoded frame 10 is shown. Each frame 10 has a start-of-frame delimiter 12, a payload field 14, an optional cyclic redundancy check (CRC) field 16, and an end-of-frame delimiter 18. A difficulty with the HDLC approach is that there is an increased likelihood of losing the 0x7E frame delimiters 12 and 18 due to bit errors as link speeds increase. In addition to an error-prone delineation, the HDLC scheme also suffers from bandwidth inefficiency since many data byte patterns must be encoded into special two-byte sequences to avoid the 0x7E frame delimiter pattern and other control characters patterns. Therefore, the HDLC scheme requires transmitting more bytes than the actual payload. Depending on the number of conflicting bytes inside the payload, the amount of actual bandwidth needed to send a packet can be quite large.
To alleviate the limitations of HDLC, a method called Simple Data Link (SDL) was developed by Bell Labs. The SDL method does not use a predetermined pattern to delineate the start and the end of the frame. Instead, the SDL method only includes a header in each frame to delineate the start of frame. The end of frame is calculated from the start of frame delimiter and a check for an optional payload CRC field.
Referring to FIG. 2, a drawing of a conventional SDL encoded frame 20 is shown. In the SDL method, a 2-byte field 22 containing a length of the payload is used as a portion of the start-of-frame delimiter. A 2-byte length CRC field 24 that follows the length field 22 is used as a second portion of the start-of-frame delimiter. The length CRC field 24 containing a CRC value for the value stored in the length field 22. The length CRC field 24 is followed by a payload field 26 and an optional payload CRC field 28. The value stored in the length field 22 does not include the 4-byte payload CRC field 28.
A receiving engine for SDL delineation has hunting logic that tracks an incoming frame 20 on a byte-by-byte basis to look for a pattern where a CRC computed on first two bytes (length field 22) matches the following two bytes (length CRC field 24). If a match is found, then the receiving engine marks a valid start-of-frame. A number of bytes following the length CRC field 24 are returned to protocol processing entities as the payload. The number of bytes is equal to the value in the length field 22.
Once the payload is retrieved, the receiving engine receives the 4 subsequent bytes as a payload CRC value. The payload CRC value is used to verify integrity of the payload. After the payload CRC field 28 is received, the receiving engine starts hunting for a length/CRC validation to look for next frame boundary.
A problem with the SDL approach is that many protocols such as Ethernet, frame relay, and payloads for multiprotocol over Asynchronous Transfer Mode (ATM) have their own built-in CRC as part of the payload. Therefore, the SDL frame 20 does not have the additional 4-bytes of the payload CRC field 28. Conventional multi-service transport protocols require special logic for handling specific protocols as part of the frame delineation engine due to the optional payload CRC field 28. The special logic must understand the particular payload format being processed. Therefore, the special logic requires complicated delineation engines that need the complication of Open Systems Interconnect data link (i.e., layer 2) lookup and processing. Such a solution is complicated, expensive, and non-scalable. Each time a new protocol is added within the payload field 26, the logic must be changed to accommodate the new protocol.
For channelized SONET/SDH applications, it is almost impossible to use conventional technology for multi-service transport over different channels, due to the complexity and bulkiness of each engine. Since protocol requirements over a single channel change, each SDL engine must be able to accommodate all types of protocols. The receiving engine cannot be used to send payload data that does not have a header that clearly identifies presence or absence of the payload CRC field 28.